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and  those  who  have  Poker  available  online  and  who  wish  to  gain  operational  proficiency. 
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The  Purpose.  This  document  is  intended  to  serve  as  a  sample  program  for  the  Poker 
Parallel  Programming  Environment  *{t].'  However,  Poker  programs  do  not  exist  in  the 
traditional  sense:  There  is  no  monolithic  sequence  of  symbolic  text.  Rather,  Poker  keeps  a 
“source  database”  which  the  programmer  can  view  and  change  using  interactive  graphics. 
Databases  and  interactive  graphics  may  be  very  convenient  for  the  programmer,  but  they 
are  not  easily  conveyed  in  hardcopy  form.  So,  in  an  effort  to  provide  some  sense  of  the 
flavor  of  Poker,  this  document  is  composed  mostly  of  annotated  pictures  produced  in  the 
course  of  a  Poker  programming  session. 

This  example  is  intended  to  be  as  comprehensible  as  possible  without  requiring  the 
reader  to  be  fully  familiar  with  the  massive  background  material.  The  presentation  is 
directed  at  two  audiences:  Those  who  do  not  have  Poker  available  but  would  like  to  see 
specific  details  in  a  form  that  is  not  as  dry  as  a  reference  manual,  and  those  who  do  have 
Poker  available  and  would  like  a  quick  way  to  gain  operational  proficiency.  Both  audiences 
can  learn  how  things  are  done  in  Poker.  For  an  explanation  of  why  things  are  done  as  they 
are,  two  papers,  written  for  general  audiences,  are  available,  one  on  Poker -jl)  and  one  on 
the  CHiP  architecture .(2).’  •  r<  >-  .  ( 

The  text  presented  here  refers  to  the  Poker  Programmer’s  Reference  Guide  [3]  and  it 
is  convenient  to  have  a  copy  available  while  following  the  example. 


The  Problem.  We  select  a  problem  which  is  easy  to  understand  and  still  illustrates  many 
aspects  of  the  system: 

Given  k  vectors  of  length  n,  produce  the  n  vector  that  is  their  elementwise  sum 
and  append  to  that  resulting  vector  the  grand  total,  i.e.  the  sum  of  ail  input 
values. 

We  will  solve  the  problem  with  a  binary  tree  based  algorithm.  Each  vector  is  treated  as 
a  data  stream  entering  a  leaf  of  the  tree.  The  leaf  simply  passes  the  value  to  its  parent. 
Each  internal  node  sums  the  pair  of  elements  received  from  its  children  and  passes  the 
result  to  its  parents.  Additionally,  the  root  accumulates  all  the  results  it  sends  out  and 
after  the  result  of  the  nth  pair  has  been  summed  in  and  sent  out,  it  passes  the  grand  total 
out.  For  the  first  pass,  we  will  use  k=8,  n=10. 

‘The  work  described  hereii  b  part  of  the  Bine  CHiP  Project  aad  baa  beet  supported  in  part  by  Office  of 
Naval  Research  Contracts  N00014-84-K-0143  aad  N00014-85-K-0328  and  NSF  Grant  DCR  8416878. 
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The  Display.  Figure  1  shows  a  typical  Poker  display  with  the  relevant  regions  indicated 
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Figure  1.  A  Typical  Poker  Display. 
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The  purpose  of  each  region  of  the  display  is  as  follows: 

field  A  region  showing  a  schematic  picture  of  the  CHiP  Computer's  lattice: 

this  is  the  region  where  most  programming  activity  takes  place. 

lattice  A  schematic  diagram  of  the  processing  elements  (PEs)  with  a  box  en¬ 

closing  those  PEs  currently  shown  in  the  field;  no  direct  user  activity  is 
available  in  the  region. 

chalkboard  The  upper  righthand  region  of  the  display  giving  status  information. 

command  line  The  area  where  textual  commands  are  given;  last  line  of  the  chalkboard. 

diagnostic  line  The  area  where  error  indications  are  given;  the  next-to-last  line  of  the 
chalkboard. 

clipboard  A  ten  line  region  of  the  chalkboard  used  for  the  display  of  transient 

information  and  available  for  displaying  files. 

Notice  that  the  display  provides  considerable  geometric  context  which  many  users  find 
helpful. 

The  Keyboard  and  Keys.  In  order  to  be  completely  precise,  the  example  is  annotated  with 
every  key  struck  by  the  programmer.  To  assist  in  making  these  strings  intelligible,  the 
accompanying  legend  (Figure  2)  will  be  useful.  Note  that  there  is  a  keypad  (Figure  3)  for 
cursor  motions.  A  keypad  key  prefixed  by  an  escape  ($)  is  called  a  “gross  cursor  motion" 
since  it  moves  a  larger  amount  than  the  “fine  cursor  motions”  which  are  unprefixed.  Users 
having  a  MOUSE  should  refer  to  Appendix  B  of  the  Reference  Guide[3]  for  alternate 
instructions. 

$  escape  key 

*<char>  denotes  striking  the  <char>  key  while  depressing  the 
control  key 

%<char>  the  <char>  key  of  the  keypad 
b  blank;  all  spacing  in  command  strings  is  for  clarity 


Figure  2.  Legend  of  Poker  Orthography 
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Figure  3.  The  Keypad  of  the  Bitmapped  Display 
and  the  Notation  for  Directional  Keys 
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1.  Once  yon  an  logged  into 
UNIX  from  ft  bitmapped  display 
and  referencing  a  clean  directory, 
type  ‘poker’  to  start  the  system. 
If  this  does  not  work,  either  Poker 
is  not  available  on  your  machine 
or  your  PATH  line  in  the  .profile 
or  .login  file  does  not  refer  to  the 
directory  containing  Poker,  e.g. 
/usr/poker/bin. 

In  subsequent  figures,  arrows  il¬ 
lustrate  the  cursor  position. 


2.  Poker  begins  in  CHiP  Param¬ 
eter  view  which  is  used  to  declare 
the  characteristics  of  the  CHiP 
computer  being  programmed.  The 
default  architecture’!  parameters 
define  a  04  processor  machine 
since  n,  the  number  of  processors 
on  the  side  of  the  nxu  lattice,  is 
given  as  na*08.  We  need  only  a  10 
processor  machine  for  our  exam¬ 
ple  so  we  must  change  the  entry 
for  n  to  be  4  by  moving  the  cursor 
east  one  character  and  striking  4. 
[%•  4|.  1 


3.  Changes  to  the  CHiP  pa¬ 
rameters  do  not  take  effect  until 
we  move  to  some  other  view,  so 
we  move  to  Switch  Settings j$s|. 
(Discussion  of  the  meaning  of  the 
other  CHiP  parameters  is  given 
in  Section  7  of  the  Reference 
Guide.) 


1  Recall  that  X(ehars)  rsfsrs  to  the 
(char)  on  the  key  pad  at  right,  t  is  aa> 
eaP<>  "i*  control,  and  t  is  a  required 
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VIEW:  Switch  Se 
LAST  PE:  1  2 


Setting  -  drew 
SAVED  PE:  NONE 


4.  To  specify  the  communica- 
tion  graph  connecting  the  proces¬ 
sor  elements  (PEs)  for  our  prob¬ 
lem,  we  draw  a  picture  of  a  bi¬ 
nary  tree  .  The  IS  PEs  are  shown 
as  boxes  with  indicss;  the  cir¬ 
cles  are  switches  through  which 
all  communication  paths  (linss  of 
the  picture)  pass.  The  root  of  our 
binary  tree  should  be  at  PE  1  2 
so  we  more  the  cursor  east.  This 
can  be  done  either  with  two  fine 
cursor  motk>ns:(%6  %Sj  or  one 
gross  cursor  motion  [S%6]  which 
is  given  by  prefixing  the  keypad 
key  with  an  escape.  (A  discus¬ 
sion  of  other  cursor  manipulation 
activities  is  given  in  Section  3  of 
the  Reference  Guide.) 


S.  An  indication  is  given  in  the 
chalkboard  of  the  index  of  the 
last  PE  referenced.  To  draw  the 
communication  paths  in  the  lat¬ 
tice,  we  set  the  cursor  mode  to 
‘draw*  {*dj  and  then  move  the 
cursor  around  the  lattice. 


0.  The  “draw*  indication  re¬ 
places  the  “null”  (no  mode  set) 
indicator  in  the  chalkboard.  We 
next  move  the  cursor  south  [S%2] 
to  the  child  of  the  root,  i.e.  PE  2 
2. 


7 


K"-  V  V  V  w  iL*  Kw  1 


I  ■!■!■!■  j 


■till 


o  o 
o  3 
o  o 
0  3 
o  o 
oflo 
0  0  0 
ofloBo 
o  0 


otLoOJo 


0  0  0  0 
3030 
0  0  0  0 
Ooao 
ooooooooo 
030303030 
ooooooooo 
030303030 
0  0  0  0 


0000 

o 

o  o 
o 


7.  The  communication  path  be¬ 
tween  the  root  and  ita  left  child  - 
ita  right  will  be  PE  2  3  -  ia  ahown 
aa  a  line.  The  proceaeora  will  be 
able  to  communicate  valuea  over 
thia  link.  Since  'drawing*  ia  atill 
in  effect,  we  can  move  weat  to  the 
(root’a)  grandchild  ($%4|. 


OOO 

mo 
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8.  The  communication  path  be¬ 
tween  child  and  grandchild  ia 
ahown  aa  before.  Groea  curaor 
motiona  move  to  the  next  PE  in 
the  indicated  direction;  on  onr 
way  to  the  great-grandchild,  we 
can  illuatrate  fine  curaor  motiona, 
which  move  to  the  next  element, 
be  it  a  twitch  or  PE  [%8|. 


9.  Notice  that  the  line  atope  at 
the  edge  of  the  awitch.  (Com¬ 
munication  pat  ha  can  enter  and 
leave  a  awitch  from  the  eight  corn- 
put  pointa,  and  they  can  croea 
over  one  another.  See  Section  8  of 
the  Reference  Guide.)  We  move 
to  PE  1  1,  a  leaf  [%8j. 
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10.  Having  reached  a  kaf,  w« 
want  to  connect  to  a  stream  of 
data  values  stored  on  the  disk. 
Sach  streams  "enter”  the  lattice 
through  "pads”;  pads  are  indi¬ 
cated  by  tiny  squares  "outside” 
the  lattice  and  they  are  created 
by  moving  the  cursor  "off*  the 
edge  of  the  lattice  [S%4|. 
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11.  We  can  draw  the  edges  to  ths 
sibling  kaf,  Le.  PE  3  1,  by  retrac¬ 
ing  our  path  back  through  PE  2 
1  [Sttfl  SX2  1X2  $964). 


12.  To  continue  the  construction 
of  the  tree  we  must  return  to  PE 
2  2,  the  child,  and  this  could  be 
done  by  retracing  the  path  back 
to  PE  2  2,  or  by  turning  off  the 
“draw*  indicator  (e.g.  with  *n) 
and  moving  the  cursor  to  PE  2 
2.  A  third  possibility  is  to  use 
the  Center  command.  We  begin 
by  typing  the  index  of  the  PE, 
[242|;  the  characters  will  be  dis¬ 
played  on  the  command  line  even 
though  the  cursor  remains  in  its 
present  position. 


13.  With  the  PE  ind«x  given  14.  We  continue  in  an  analogous  15.  At  this  point  we  have  made 

on  the  commend  line,  Center  [*c|  way  to  define  the  binary  tree  end  a  mistake  which  must  be  cor- 

will  move  the  cnreor  to  the  PE.  iU  pads  ($%2  $%1  t%2  t%8  rected.  This  is  done  by  chang- 

$962  t%2 $968  $968  $968  $968  $963  ing  the  mode  from  “draw"  to  ‘re- 


$96«  $968  $%«  t%2\.  move"  [*r]. 
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18.  The  change,  reflected  in  the  17.  With  the  arrow  corrected,  we  18.  The  layout  of  the  binary 
chalkboard,  allow*  n*  to  ‘backup’  can  reset  the  indicator  to  ‘draw*  tree  into  the  lattice  is  completed: 
over  the  line,  removing  the  set-  [*d]  and  continue  with  the  graph  Eight  data  streams  enter  at  the 
ting  [$968].  layout  [$964  $962  $962  $96«  $964  leaves  of  the  tree  and  a  result 

$964  $962  $963  $962  $968  $967  stream  exits  at  the  root.  The 
1962  $962  162  c  $968].  completed  switch  definition  is  given 

in  Figure  4.  To  assign  processes 
to  each  of  the  processors,  we 
change  to  the  Code  Nam*  View 
[$cj. 
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19.  Notice  that  the  iwitchea  have 
been  removed  and  the  PE  boxee 
enlarged  to  hold  more  informa¬ 
tion.  In  Code  Namee  View  we 
aaaign  proceeeee  to  proceaeon  by 
entering  into  the  PE  boxes  the 
names  of  the  (yet  to  be  written) 
routines.  The  window  for  the 
code  name  is  centered  one  line 
down  from  the  top  of  the  box,  so 
we  move  down  to  it  (%2|  and  en¬ 
ter  the  text  [root]. 


20.  The  name  (of  np  to  10  char¬ 
acters)  is  clipped  to  the  first  five 
characters.  Ths  four  remaining 
lines  of  the  PE  box  are  also  vis¬ 
ited  by  fine  north/sonth  cursor 
motions  and  are  used  for  speci¬ 
fying  (actual)  parameters  to  the 
process.  Since  we  intend  for  the 
stream  length  to  be  a  parameter, 
we  enter  its  actual  value  now  \%2 
10]. 


21.  As  before  gross  cursor  mo¬ 
tions  move  from  PE  to  PE,  so 
we  move  to  the  child  PE[$%2); 
the  cursor  will  appear  at  the  top 
of  the  box  in  what  is  called  the 
‘home*  poeition. 
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22.  To  ent«r  iu  procau  coda 
nuna  in  tha  appropriate  window, 
wa  mova  down  to  tha  first  lina 
[%2\.  Tha  interior  nodaa  will  ba 


23.  Sinca  there  are  several  PEe 
that  arill  receive  this  same  text,  it 
ia  convenient  to  buffer  the  entries 
(*bj.  The  buffered  cell  is  shown  ia 


given  the  ‘inode’  process  name  the  clipboard  region  of  the  chalk* 
and  the  stream  length  actual  pap  board, 
rameter  (inode  %2  10] . 


24.  To  depoeit  the  buffered  val¬ 
ues  in  another  PE,  say  the  sib¬ 
ling  PE  2  3,  we  can  type  the  in¬ 
dex  of  the  recipient  PE;  but  to 
avoid  the  possibility  of  the  in¬ 
dex  specification  being  treated  as 
text,  we  must  move  out  of  the 
window  and  to  the  ‘home’  posi¬ 
tion  of  the  PE  [%5|.  Then  we 
enter  the  indices  [243]  which  are 
shown  on  the  command  line. 


25.  With  the  recipient  indices 
specified,  a  deposit  command  (*d| 
copies  the  buffered  values  into  the 
cell.  (The  cursor  doss  not  move 
as  a  result  of  the  deposit.  For 
a  full  discussion  of  the  buffer- 
deposit  mechanism,  see  Section  9 
of  ths  Reference  Guide.) 


20.  Another  way  to  use  the  de» 
posit  feature  is  to  move  the  cur¬ 
sor  to  ths  recipient  PE  and  invoke 
ths  deposit,  because  when  ao  PE 
indices  are  specified  on  ths  com¬ 
mand  lias,  the  deposit  is  to  ths 
PE  containing  ths  cursor.  To  il¬ 
lustrate  this  case,  we  move  to  PE 
2  1,  the  grandchild  [$%4|,  and  ex¬ 
ecute  a  deposit  [*d|. 


27.  Similar  motions  can  easily 
specify  all  of  the  internal  node 
processes  [S%3  *d  S%6  ‘d  S%9 

*d|. 
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31.  A  deposit  [*d]  assigns  the 
buffered  text  to  ill  of  the  fourth 
row  PEe.  The  binary  tree’*  pro- 
ceMee  are  now  assigned.  (See  Fig¬ 
ure  S.) 


32.  The  next  step  is  to  define 
the  sequential  code  for  each  pro¬ 
cess.  This  uses  the  XX  pro¬ 
gramming  language  and  is  usu¬ 
ally  done  on  the  companion  ter¬ 
minal  using  a  standard  editor.  (If 
so,  the  terminal  should  refer  to 
the  sample  directory;  if  a  com¬ 
panion  terminal  is  not  available, 
ths  user  can  exit  Poker  ($  *e) 
to  prepare  the  processes.)  The 
pro  csss  code  is  given  one  pro 
cess  per  fils  with  the  naming  con¬ 
vention  <process  name>.x.  (To 
save  typing,  these  files  can  be 
found  in  /usr/poker/lib/Playing 
Poker.)  We  give  the  XX  codes 
for  the  three  tree  processes. 


code  leaf(n); 
trace  x; 

ports  tn, parent; 
begin 

Int  x,1,n; 
for  1  :■  1  to  n  do 
begin 
x  <-  In; 
parent  <-  x 
end 

end. 


33.  The  leaf  process,  stored  in  the 
file  leaf.x,  simply  reads  a  value 
from  its  input  port,  in,  and  writes 
it  to  its  parent.  Notice  that  data 
is  transferred  one  value  at  a  tune 
using  an  aoaignment-like  operator 
(<-).  (Mors  information  on  the 
XX  language  is  given  in  Section 
12  of  the  Reference  Guide.) 
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cod*  1node<n); 
tr«c*  z; 

ports  Ichlld.rcfiild, 
parent; 

begin 

int  x.y.z.i.n; 
for  1  :•  1  to  n  do 
begin 

x  <-  lchild; 
y  <-  rchitd; 

Z  :•  xey; 
parent  <-  z 
end 

end. 


code  root(n); 
trace  «,z; 

ports  lchild, rchild, 
parent; 

begin 

int  w, x.y.z.i.n; 

«  :•  0; 

for  1  :■  1  to  n  do 
begin 

x  <-  1  ch lid; 
y  <-  rcftlld; 
z  :■  xey; 
parent  <•  z; 

m  :•  w  ♦  Z; 

end; 

parent  <-  w 
end. 
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34.  The  internal  nodes  reed  val¬ 
ue*  from  their  child  processes, 
turn  the  values  received,  and  send 
the  result  to  their  parents. 


35.  The  root  acts  like  any  inter¬ 
nal  node,  bnt  it  also  retains  a  run¬ 
ning  total  (w)  which  it  appends 
to  its  output  stream  at  the  end  of 
the  computation. 

Having  referred  to  neighboring 
processes  by  port  names,  we  must 
now  defins  them. 


30.  The  Port  Names  View  is  en¬ 
tered  [Spj  ihoering  a  display  sim¬ 
ilar  to  that  of  Code  Names.  The 
chief  difference  is  that  the  PE 
box  is  broken  np  into  eight  win¬ 
dows,  one  far  each  compass  point. 
The  windows  contain  names  of 
at  most  10  characters  which  are 
clipped  to  the  irst  five.  The  fine 
cursor  motions  move  to  the  win- 
doers;  gross  cursor  motions  move 
between  PE  boxes. 


□ 

□ 


37.  Using  th«  fins  Conor  key, 
we  mov*  to  th«  wMt  port  win¬ 
dow  [%4]  and  enter  the  port  nuns 
and  in  the  laaf  procaaaaa  for  the 
external  data  stream  [in).  Simi¬ 
larly,  wa  can  mow*  to  tka  aontk 
window  [9(2)  and  antar  tka  other 
port  name  [parent). 


38.  Tka  windows  are  small  (5 
ckaractars)  although  tka  actual 
names  can  be  up  to  16  characten 
in  length.  To  see  the  undipped 
entries  wa  can  use  tka  display  key 
[*y|.  Tka  result  is  shown  on  tka 
diagnostics  line. 


30.  We  can  continue  making  en¬ 
tries  by  using  gross  motions  to 
mows  to  new  PEe  [S9(2|  and  then 
fine  motions  to  more  to  the  port 
windows  [%8  ichild  %6  parent  %2 
rckild).  Continuing  in  this  way 
[t%2  %8  parent  %4  in  $%2  %0 
parent  %2  in  l%6  %8  parent  %2 
in)  we  complete  a  call  that  can  be 
buffered  [*b|  and  reused  [8%6  *d|. 
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43.  Notice  that  the  arrow  in 
the  achematic  changed  poeition  to 
point  to  the  poeition  of  the  laat 
pad.  Pada  are  numbered  dock- 
wise  starting  from  the  northweet 
corner.  To  define  the  stream 
name  “datain*,  we  simply  type 
into  the  ‘name*  window  pane 
[datainj. 


44.  Streams,  sequences  of  data 
values,  are  either  files  by  them¬ 
selves  or  they  are  grouped  into 
a  file  by  being  placed  “side-by- 
side*  .  The  index  describes  which 
position  in  the  file  the  stream  oc¬ 
cupies,  Le.  which  field  it  is  in  each 
record.  Assuming  the  leaves  are 
numbered  in  the  normal  “left  to 
right*  order,  pad  9  corresponds 
to  leaf  1  and  thus,  we  assume, 
to  stream  1.  So  we  move  east  to 
the  index  pane  of  the  pad  window 
[%6|  and  enter  the  index  [1|. 


45.  The  direction  refers  to  whether 
this  stream  is  an  input  or  output 
stream.  Streams  can  only  be  uni¬ 
directional.  We  specify  input  j*i). 
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46.  Sine*  all  of  tha  lami  will 
hav«  eaaentially  tha  lima  entriaa 
(except  for  index),  wa  can  buffer 
thin  entry  [*b|  in  anticipation  of 
depositing  it  in  tha  other  leaf  po¬ 
sitions  with  an  iterated  deposit. 


47.  To  give  tha  iteration  parame¬ 
ters  for  tha  iterated  deposit  com¬ 
mand,  wa  move  to  the  command 
line  using  tha  *home*  key  [965). 
Than  wa  give  tha  first  element  of 
the  iterated  sequence,  tha  last  el¬ 
ement,  and  the  amount  by  which 
the  step  is  to  change,  La.  by  -1 


46.  Tha  multiple  pad  deposit  can 
now  be  specified  with  a  single  key 
[~d].  (A  full  description  of  iter¬ 
ated  deposit  is  given  in  Section 
11  of  the  Reference  Guide.) 
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49.  Notice  that  unlike  depoeite  in 
the  other  viewe,  which  copy  the 
buffered  data  exactly,  depoeit  in 
10  Names  updates  the  index  by 
1  as  it  deposits.  This  increment¬ 
ing  property  explains  why  we  it¬ 
erated  through  the  la  ares  in  the 
order  in  which  their  streams  ap¬ 
pear  in  the  file.  Next  we  go  back 
to  the  output  pad  [  %5  %2\  us¬ 
ing  wrap  around  and  enter  the 
stream  [dataout  %6  1  *o).  This 
completes  the  10  Names  specifi¬ 
cation;  the  final  form  is  shown  in 
Figure  7. 


50.  Having  completed  the  source 
specification  of  our  example  pro¬ 
gram,  we  take  the  precaution  of 
making  a  backup  copy  of  our 
database.  This  is  done  by  mov¬ 
ing  to  the  command  line  [%5| 
and  specifiying  the  "copy*  com¬ 
mand  [copy  6).  (This  is  a  general 
file  manipulation  facility.)  The 
appropriate  transfer  for  backing- 
up  is  to  copy  all  internal  source 
database  entities  [*,]  to  the  cur¬ 
rent  directory  [.].  (File  manage¬ 
ment  is  discussed  is  Section  0  of 
the  Reference  Guide.) 


51.  All  execute  commands  are 
invoked  with  the  execute  key 
[*x|.  (In  the  case  of  "copy* ,  the 
completion  is  reported.)  Other 
execute  commands  perform  text 
substitution  (replace),  associate 
streams  with  files  (bind),  and  ex¬ 
ecute  programs  (run).  A  list  of 
the  available  commands  is  given 
when  one  "executes”  a  blank 
command  line.  When  one  exe¬ 
cutes  a  parameterless  command, 
the  syntax  for  that  command  is 
given.  Incidently,  in  a  view  the 
command  for  that  view  gives  a 
list  of  the  legal  key  strokes. 
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52.  Having  compl«t«<i  the  source  53.  Firtt  we  display  the  file  of  54.  To  be  need  by  Poker,  the 


database  specification  for  oar  pro-  sample  data  that  will  be  used  to  file  most  be  copied  into  the  car- 


gram,  we  move  to  the  Command 
Request  view  where  we  prepare 
to  ran  the  program  [Sr]. 


I 

& 


test  the  program.  Files  are  dis¬ 
played  by  giving  the  file  name  on 
the  command  line  followed  by  *f. 
The  file  is  printed  in  the  Clip¬ 
board  region  of  the  screen  with 
the  lines  clipped,  if  necessary 
(/oar/ poker /lib/ Playing  Poker/tes 
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rent  directory.  Since  this  is  a  file 
rather  than  a  Poker  database  en- 
tity,  we  ose  the  UNIX  copy  com¬ 
mand  rather  than  the  Poker  copy 
command.  UNIX  commands  are 
executed  from  Poker  using  the 
'shell*  execute  command  with 
the  UNIX  command  as  a  param¬ 
eter;  thus,  we  type  'shell*  fol¬ 
lowed  by  the  text  UNIX  is  to  ex¬ 
ecute  follwed  by  *x.  [shell  6  cp 
4/>isr /poker/ lib/ Playing  Poker/test 
6.*x| 


1.  «,  J 

3,  3,  5 ,  j  i  > 

«.  1,  8, 

3,  4,  2, 

-1,  -1,  -1,  - 

-S,  -7,  - 

-3,  -S,  -S,  - 

-i,  -a,  - 

-3,  -4,  -2,  - 

1.  1,  1, 


1.  « 

«,  3,  2, 

a,  S,  4, 

2,  2, 
-1,  -1.  -1. 
-2.  -1, 

•4,  -3,  -2, 
-4, 

■2,  -7,  -2, 

1.  1.  1, 


55.  Th«  fLU,  now  in  th«  currant 
directory,  is  composed  of  random 
value*  and  their  negation*,  *o 
they  ram  to  0.  It  ha*  10  record* 
of  8  field*  each,  and  can  therefore 
be  interpreted  a*  8  stream*  (laid 
out  *ide-by-*ide)  each  containing 
10  element*. 
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58.  Poker  expects  these  stream* 
to  be  in  a  special  format  which 
is  produced  by  a  utility  program, 
called  packlO,  described  in  Ap¬ 
pendix  B.  We  use  the  shell  com¬ 
mand  again  to  format  the  file 
[shell  4  packlOi  test*  vector*  *x| 
and  name  the  result  vector*. 


57.  To  associate  the  8  streams, 

vector  1,  vector  2 .  vector  8 

with  the  8  stream*  declared  in  the 
10 Names  view,  detain  1,  detain 
2, ...,  detain  8,  w*  bind  the  name* 
together  using  the  execute  com¬ 
mand  for  that  purpose,  [bind  5 
detain  b  vectors  *x|. 


%  N> 


58.  The  dataout  stream  moat 
also  ba  given  an  external  name 
with  tha  binding  command  [bind 


59.  Tha  to  area  data  baaa  moat 
ba  compiled  to  convert  it  into  a*> 
eambly  coda.  (Tha  raanlt  of  eom- 


60.  Having  converted  the  source 
databaae  to  executable  form,  hav¬ 
ing  loaded  tha  object  code  into 


£ 


b  d&tftont  b  result*  *x).  Ths  de¬ 
fault  name  for  files  is  the  stream 


name. 


Ky 
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piling  <nama>Jt  is  <nama>.a.) 
Tha  assembly  coda  must  ba  con¬ 
verted  into  object  form.  (Tha 
result  of  assembling  <name>.s 
is  <name>-o.)  The  object  coda 
is  than  coordinated  •  an  experi¬ 
mental  optimisation  activity  that 
is  not  implemented  in  tha  dis¬ 
tributed  version.  Tha  communi¬ 
cation  graph  must  ba  compiled, 
producing  tha  connections  (read¬ 
able)  and  conn  actions. o  files.  Tha 
resulting  object  coda  is  loaded 
into  the  Pringle  emulator.  All  of 
these  ectrvitiee  are  implemented 
by  one  make  operation  [$m|. 
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the  emulator  and  having  bound 
streams  to  files,  it  is  time  to  ex¬ 
ecute  the  program.  It  can  be 
done  from  the  Command  Request 
View,  but  to  watch  the  progress 
of  the  execution,  we  must  go  to 
the  TVace  View  [St j. 
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01.  Tit*  Tract  View  shows  a  dis¬ 
play  aimilar  to  Coda  Namaa  Viaw 
-  indaad,  tha  procaaa  nama  is 
given  in  each  PE  box.  However, 
instead  of  tha  (actnal)  parame¬ 
ters  being  listed  after  the  procaaa 
name,  the  values  of  the  trace  vari¬ 
ables  (initially  0)  are  listed.  Each 
time  execution  stops,  the  current 
values  of  the  traced  variables  are 
given.  To  execute  the  program 
until  the  first  event  takes  place, 
we  use  the  event  command  (*e|. 


02.  The  execution  is  initiated  03.  The  values  that  have  changed 
which  can  be  seen  because  each  are  highlighted  aa  the  execution 
PE  has  aa  equal  sign  in  the  home  proceeds  in  order  to  call  our  ap¬ 
position  showing  that  it  is  run-  tention  to  the  activity.  To  con¬ 
ning.  We  can  execute  two  more  tinue  the  execution  until  all  PEs 
events  with  [*e  *e).  are  finished  and  to  show  a  trace 

of  the  progress,  we  type  [continue 


[I! 


□□□ 

□□□ 


-gnciq- 


VIEW:  Code  Naaes 
UT  PE:  I  1  si 


S4.  Execution  continue*;  when  nil 
PE*  have  halted,  we  note  the  cor¬ 
rect  reault  (0)  in  the  traced  vari¬ 
able  in  the  root. 


OS.  Flushed  with  aucceM  at 
having  gotten  the  right  answer, 
we  try  another  test  to  illustrate 
how  successive  programs  are  exe¬ 
cuted.  We  will  for  simplicity  use 
a  new  file,  ‘double fils*,  which  is 
just  two  copies  of  sector*,  [shell 
fccpft/usr/poker/lib/Playiag  Poker 
/double filet.  *xj.  Since  vectors  is 
already  formatted  we  do  not  have 
to  format  doublefile.  To  change 
the  stream  length  actual  param¬ 
eter,  we  move  to  Code  Names 
View  [$cj. 


60.  We  can  make  a  uniform  sub¬ 
stitution  of  20  (the  new  stream 
length)  for  every  occurrence  of  10 
[replace  ft  10  ft  20]. 


^  nT*  i 


67.  Execution  of  the  command  68.  We  moat  also  bind  the  new 
(*xj  implement*  the  aabetitntion.  file  to  the  inpat  data  stream* 

[bind  b  detain  b  donblefik  *xj. 
Notice  that  by  not  chanting  the 
file  name  associated  with  the  oat- 
pat  *tream,  we  will  limply  writ* 


69.  We  move  to  Command  Re¬ 
quest  View  [Sr]  where  we  load  j'l) 
the  current  copy  of  the  compiled 
cod*. 
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70.  Next  we  move  on  to  Trace 
View  [$t]  where  we  (pacify  that 
we  want  to  run  (thin  phase  1)  on* 
til  all  of  the  PEs  complete  execu- 
tion  [run  4  1  4  all  4  trace  ‘xj. 


71.  The  emulator  execution  pro¬ 
ceeds  autonomously  until  the  con¬ 
dition  ia  realised.  (Users  who  do 
not  wish  to  run  all  52,000  ticks  of 
the  example  can  interrupt  execu¬ 
tion  with  *\j. 


72.  Again,  the  sero  result  is 
achieved.  To  leave  Poker  and 
to  save  the  source  state,  we  exit 
(**•!■ 
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Exercise 


Although  there  are  many  features  of  Poker  that  have  not  been  illustrated,  enough  of 
the  system  has  been  described  to  enable  the  reader  to  solve  the  following  problem. 

Problem  Let  the  three  streams  listed  below  be  the  coefficients  of  three  poly¬ 
nomials  given  in  increasing  powers  of  x.  Define  a  “slave”  process  that  receives 
an  x  value  from  a  “master”  process,  reads  in  the  coefficents,  evaluating  the 
polynomial  as  it  does,  and  returns  the  result  to  the  master.  The  master  pro¬ 
cess,  which  has  the  three  x  values  as  parameters,  sends  a  value  to  each  slave, 
reads  the  result  from  each  slave,  adds  together  the  results  and  outputs  the  sum 
as  a  (one  element)  stream. 

It  is  suggested  that  the  slave  processes  have  the  number  of  terms  (degree  4-  1)  of  the 
polynomial  as  a  parameter. 

The  three  coefficient  streams  of  length  8,  5  and  4,  respectively,  are  assumed  in  the 
following  example  to  be: 


1.004 

5.078 

2.953 

49.827 

0.553 

5.167 

3.590 

13.422 

0.875 

0.333 

9.244 

7.754 

6.000 

1.144 

0.253 

0  096 

1.000 

The  points  at  which  the  polynomials  are  to  be  evaluated  are  assumed  to  be,  respectively, 
1  Oil,  2.622,  3.14. 

As  a  hint  to  solving  the  exercise,  we  give  the  Code  Names  View  for  a  possible  solution, 
as  well  as  tue  final  result  (highlighted)  of  the  traced  computation. 


Mon  Sep  11 

03:24 

VIEW: 

Code 

Nuei  -  Interconnect 

PHASE : 

1 

LAST  PE: 

1  1 

SAVED  PE:  NONE 

